|
|
 |
|
|
|
|
32: 'Delegate to private methods, where only one will be able to
33: 'process the message.
34:
35: Set LocalObject = argObject
36:
37: Call increaseFunds(LocalObject)
38: Call decreaseFunds(LocalObject)
39:
40: Set LocalObject = Nothing
41: End Function
42:
43: Private Function increaseBalance(ByRef argObject)
44: 'Make sure incoming object is of type Deposit
45: If TypeName(argObject) <> Deposit Then
46: Exit Function
47: End If
48:
49: 'It's a Deposit object
50: CurrentBalance = CurrentBalance + argObject.Amount
51:
52: End Function
53:
54: Private Function decreaseBalance(ByRef argObject)
55: 'Make sure incoming object is of type Withdrawal
56: If TypeName(argObject) <> Withdrawal Then
57: Exit Function
58: End If
59:
60: 'It's a Withdrawal object
61: CurrentBalance = CurrentBalance - argObject.Amount
62: End Function
63:
64: Properties:
65: AccountNumber
66: CurrentBalance |
|
|
|
|
|
|
|
|
Before explaining Listing 4.1, note several things. First, the theDeposit object doesn't have an AccountNumber property. Why? There's not any hard and fast rule, but to minimize the chance of violating encapsulation, the decision was made that theDeposit object be a controller of events between some user interface and the business domain object, theBasicPersonalCheckingAccount. Also note that theDeposit object has only one method and attribute (or property). This is intentional, to keep the example simple. In reality, your object's class will have at least two or three methods. Finally, check out the regular use of functions, as opposed to subs. Functions give you the flexibility of |
|
|
|
|
|